Improve handling of disable/enable/ignore directives #123
+525
−98
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Thanks for porting this over @anomiex ! I will look at this at a later point in time and am tentatively earmarking this PR for the 4.0.0 release as it constitutes a bigger change than I deem responsible for the 3.x branch. |
|
Since it sounds like 4.0.0 is probably coming fairly soon after 3.8.0 now, that seems fine with me. 👍 Also, since 4.0.0 is dropping old PHP support, I'm going to ignore the failing PHP 5.4 test. 🙂 Too bad it cancelled the rest of the tests after that one failed. |
The current method, listing codes to disable and a list of exceptions to that list, still has trouble with some cases. For example, disabling a standard, re-enabling a category within that standard, then ignoring or disabling a sniff within that category cannot be handled. We'd need a list of exceptions to the exceptions, and possibly a list of exceptions to that list too, and figuring out how to keep those lists up to date as new directives are encountered could prove to be confusing. Since the standard→category→sniff→code hierarchy is supposed to be thought of as a tree, let's store the ignore list that way instead. Manipulating the branches of the tree is straightforward no matter what directives are encountered. In this implementation I've favored speed over space: there are cases where we could prune a subtree that would evaluate to "ignore" or "don't ignore" for any possible input, but detecting that doesn't seem worth the time when it's not likely there will be so many enable or disable directives that the wasted space will be a problem. Fixes PHPCSStandards#111
anomiex
force-pushed
the
fix/ignore-list-handling
branch
from
5ea7447 to
7338e5a
Compare
jrfnl
added a commit
that referenced
this pull request
Mar 20, 2024
Links in the link lists have to be unique and as all issue/PR sources (this repo, Squizlabs repo, PEAR repo) use numeric issue references, there will be duplicate/overlapping numbers at some point. To prevent this, I'm proposing the following change: * Links to _this repo_ will continue to use simple issue number links, i.e. `[#123]`. This will keep things most straight forward for new content being added to the changelog. * Links to the _Squizlabs repo_ will get a `sq` prefix in the link reference. This means the link reference will need to be added where the link is used, i.e `[#123][sq-123]`. * Links to the _PEAR repo_ will get a `pear` prefix in the link reference. Again, this means the link reference will need to be added where the link is used, i.e `[#123][pear-123]`. This commit makes it so for all existing issue/PR links in the changelog. Related to 244
jrfnl
added a commit
that referenced
this pull request
Mar 20, 2024
Links in the link lists have to be unique and as all issue/PR sources (this repo, Squizlabs repo, PEAR repo) use numeric issue references, there will be duplicate/overlapping numbers at some point. To prevent this, I'm proposing the following change: * Links to _this repo_ will continue to use simple issue number links, i.e. `[#123]`. This will keep things most straight forward for new content being added to the changelog. * Links to the _Squizlabs repo_ will get a `sq` prefix in the link reference. This means the link reference will need to be added where the link is used, i.e `[#123][sq-123]`. * Links to the _PEAR repo_ will get a `pear` prefix in the link reference. Again, this means the link reference will need to be added where the link is used, i.e `[#123][pear-123]`. This commit makes it so for all existing issue/PR links in the changelog. Related to 244
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
The current method, listing codes to disable and a list of exceptions to that list, still has trouble with some cases. For example, disabling a standard, re-enabling a category within that standard, then ignoring or disabling a sniff within that category cannot be handled. We'd need a list of exceptions to the exceptions, and possibly a list of exceptions to that list too, and figuring out how to keep those lists up to date as new directives are encountered could prove to be confusing.
Since the standard→category→sniff→code hierarchy is supposed to be thought of as a tree, let's store the ignore list that way instead. Manipulating the branches of the tree is straightforward no matter what directives are encountered.
In this implementation I've favored speed over space: there are cases where we could prune a subtree that would evaluate to "ignore" or "don't ignore" for any possible input, but detecting that doesn't seem worth the time when it's not likely there will be so many enable or disable directives that the wasted space will be a problem.
Suggested changelog entry
Fixed bug #111: Improve handling of disable/enable/ignore directives
Related issues/external references
Fixes #111
Types of changes
Technically this could be considered a breaking change, since
PHP_CodeSniffer\Tokenizers\Tokenizer->ignoredLineshappens to be public and this changes the values stored there. Is that really a public API though?PR checklist